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Rejection I tniW.lSU.S.C. 102 
Claims 15, 16, and 18-20 are rejected under 35 U.S.C J 02(e) as being anticipated 

by United States Patent No. 6,618,388 issued to Yip el a), on September 9, 2003. The 

Office Action states that Yip et al. discloses all of the elements of applicant's claims. 

This ground of rejection is respectfully traversed for the following reason. 

Applicant notes that, generally, he previously stated that, notwithstanding the 
Office Action's assertion to the contrary. Yip ct al. docs not disclose a memory for 
establishing a correspondence association between aHHtwmm within a local area Ethernet 
network and a ddresses of ports in the metropolitan area Ethernet network, as required by 
applicant's claim 15. Instead, there is no mention ol" ports whatsoever in Yip et al. 
Furthermore, even if the notion of ports is implied by the fact that there is a metropolitan 
area network in Yip et al., nevertheless, there is no teaching or implication of a memqrv 
that is for establishing a correspondence association between addresses within nt least one 
local area Ethernet network and addresses oP ports in the metropolitan area Ethernet 
network, as required by applicant's claim 15. 

Indeed, rather than using associations between ports of the edge switches and 
addresses in a local area network, Yip et al. relates to a virtual metropolitan area network 
(VMAN) that segregates user traffic using VMAN tags. At the edge switch or the 
metropolitan area network to which a packet is rooted the additional VMAN tags that 
have been added to the packet are stripped off. Thus, applicant's claim 15 is allowable 
over Yip et al. under 35 U.S.C. 102. Since claims 16 and 18-20 depend from, and hence 
include all the limitations of, claim 15, they too are allowable over Yip et al. under 35 



i U.S.C. 102. 



In response, tlie present Office Action slated that "it is inherent that the edge 
switch should have ports with memory, where packets are queued before transmission, so 
that incoming data from the input port arc channeled to the specific output ports after 
performing a look-up in a switching or routing table". 

Applicants believe that the Office Action's statements are irrelevant to applicant's 
invention as claimed, even assuming the Office Action to be correct. In this regard, 
applicant notes that the memory of the ports mentioned by the Office Action is irrelevant 
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to applicant's claim, as such memory would only serve the purpose, as pointed out by the 
Office Action, to temporarily store packets for transmission. Thus, the only possible 
element stated by the Office Action that might correspond to applicant's memory is the 
Office Action's proposed switching or routing tabic. 

However, such a table would merely associate each particular destination address 
with a particular output port of the switch that connects in the direction of that destination 
address. For example, such a routing tabic would indicate that a packet arriving at the 
switch and destined for address A should be output at port A or the switch. It is 
important, however, to keep in mind that such addresses are addresses wjtfyjiJhc 
particular network through which the pack et is traveling. Thus, the addresses of the 
routing table in a LAN are only LAN addresses while the addresses in the routing table in 
WAN are WAN address. Consequently, the association of destination address and port in 
the routing table mentioned by the Office Action are not the correspondence association 
between addresses within a local area Ethernet network and addresses of ports in a 
metropolitan area Ethernet network, as required by applicant's invention. In conventional 
routing tables here is nji association between addresses within a local area Ethernet 
network and addresses of ports in the metropolitan area lithernct network. 

Since the Office Aetion admits diat there is no association between addresses with 
a local area Ethernet network and address of those ports in Ihe metropolitan area Ethernet 
network, and merely relies on the inherency of conventional routing tables to provide that 
element, and since applicant has shown thai a conventional routing table that might be in 
employed by Yip et al. has no such association, therefore, applicant's claims arc 
allowable over Yip et al. under 35 U.S.C. 102. 

Rejection Und er 35 U.S.C. 103(h) 
Claims 1-14, 28-31 and, 33-38 are rejected under 35 U.S.C. 103(a) as being 

unpatentable over United States Patent No. 6.807,172 issued lo Lcvcnson et al. on 
October 1 9, 2004 in view of Yip et al. 

This ground of rejection is respectfully traversed for the following reasons. 

The Office Action states that Levcnson et al. does not teach the encapsulation of 
Ethernet packets, as required by applicant's claims, and applicant agrees lhal it does not. 
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To supply this encapsulation element, the Office Action cites Yip ct al. 1 lowever, Yip et 
al. is unable to supply the encapsulation element of applicant's claims. 

Applicant previously stated that applicant and Yip ct al. teach different things with 
the use of the term "encapsulating". In response, the Office Action states that "in 
telecommunication, encapsulation is defined as the inclusion of' one data structure within 
another structure and the process". This requirement is met, according to the Office 
Action, by the addition of the VMAN tag to the input frame. 

Assuming for argument sake, that applicant agrees io the Office Action's 
definition that encapsulation is defined as the inclusion of one data structure within 
another structure", the language of applicant's claims is not met by Yip et al. when all of 
the words of applicant's claims are taken into uccount. 

Applicant's claim 1 requires encaosulatinft the contents of a first Ethernet packet 
received at a port of a switch of a metropolitan area Ethernet network in at least one 
enca psulating Ethernet packet . Thus, there is a first Ethernet packet, and its contents 
must be, in their entirety, per the Office Action's definition, included within at least a 
second other such Ethernet packet, the encapsulating Ethernet packet. One must keep in 
mind that any mere type of encapsulation will not meet the requirement of applicant's 
claims. It must be the same type of encapsulation specified by applicant. In other words, 
the contents of the whole first Ethernet packet must be contained in one Ethernet packet, 
or the contents of the whole first Ethernet packet must be divided up so that each 
resulting section is contained within an entire l-thernct packet. As a result, there now 
must be at least two source addresses, the original one of the lirst lithemct packet and a 
new one for the encapsulating Ethernet packet, and there must likewise be at least two 
destination addresses, the original one of the first Ethernet packet and new one for the 
encapsulating Ethernet packet. Of course, the old source address and the old destination 
addresses arc included within the payload portion of the new Ethernet packet. 

In Yip el al, however, there is no teaching of Ethernct-in-Ethernct encapsulation 
even according to the Office Action's own proposed definition of encapsulating. There is 
no second packet that encapsulates a first packet, i.e., according to the Office Action's 
definition, there is no teaching of including a first packet wjthin a second packet. Instead, 
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what actually is taught in Yip et al. is that the original packet is merely modified with the 
inclusion of the VMAN tag. (See Yip ct al., FIG. 2 and its associated description, i.e., 
column 4, line 49 through column 5, line 42 and especially column 5, lines 34-42, and 
FIG. 3 and its associated description, column 5, line 42 through column 6, line 1 1 .) Thus, 
while there is an addition to ihc original packet, there is no teaching of including a first 
packet within a second packet, as is required by applicant's claim language and the 
definition suggested by the Office Action. In oihcr words, the first packet is not 
contained within a second packet. Instead, in direct opposition u> the language of 
applicant's claims, it is the VMAN tag that is encapsulated within the first packet. 
However, the VMAN tag is not an Ethernet packet. Thus, even if one views adding the 
VMAN tag as a form of. encapsulation generally, this type of encapsulation is 
fundamentally different from the encapsulation described in applicant's claim, and it is 
clearly not the Ethernet packet within Ethernet packet encapsulation required by 
applicant's claim. 

Clearly then, it can be seen that applicant is using the word "encapsulation" in 
accordance with its general meaning, but Yip ct al., is using the word "encapsulation" in 
accordance with its own specific meaning as explained in the Yip ct al. specification, 
which is not the same as, or in accordance with, Ihc definition proposed by the Office 
Action. 

Thus, even without importing any content from applicant's specification into the 
claim, but instead simply making sure to factor in all of the words of applicant's claim, 
even using the definition of encapsulation suggested by the OITicc Action, Yip ct al. does 
not teach encapsulation of Ethernet packets within Ethernet packet, as recited in 
applicant's claims 1-14, 28-31 and 33-38. Likewise, Levenson et al. does not teach 
encapsulation of Ethernet packets either. Thus, the combination or Yip et al. and 
Lcvcnson et al. cannot teach encapsulation of Ethernet packets. Since applicant's claims 
1-14, 28-31 and 33-38 require encapsulation of Ethernet packets, the Yip ct al. and 
Levcnson et al. cannot make applicant's claims obvious under 35 U.S.C. 103. 
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The foregoing applies to claims 22-24 and 25-27, which require the same lype of 
encapsulation as does claims 1-14, 28-31 and 33-38 and which does not exist in the 
combination of Lcvenson ct al. and Yip et al. 

Thus, applicant's claims 22-24 and 25-27 are allowable over the combination of 
Levcnson et al. and Yip et al. under 35 U.S.C. 1 03. 

Conclusion 

It is respectfully submitted that the Office Action's rejections have been overcome 
and that this application is now in condition for allowance. Reconsideration and 
allowance are, therefore, respectfully solicited. 

If, however, the Examiner still believes that there are unresolved issues, he is 
invited to call applicant's attorney so (hat arrangements may be made to discuss and 

resolve any such issues. 

In the event that an extension of time is required for this amendment to be 
considered timely, and a petition therefor does not otherwise accompany this amendment, 
any necessary extension of lime is hereby petitioned for, and the Commissioner is 
authorized to charge the appropriate cost of such petition to (he Lucent Technologies 
Deposit Account No. 12-2325. 



Respectfully, 
llija tladzic 




Cugcrfc J. Kosenthal, Attorney 
Reg. No. 36,658 
732-949-1857 



Lucent Technologies Inc. 
Date: ' 



:hnoiogies inc. 
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